既然昨天聊到了驗收條件（Acceptance Crtieria，簡稱 AC，後面皆以此簡稱)。，就乾脆接續著聊對於新人容易搞混的另一個用詞「完成的定義」(Definition of Done，簡稱 DoD，後面皆以此簡稱)。

第一次知道這個詞是在 Scrum Guide 裏，而在 2020 版本的 Scrum Guide 亦把 DoD 作為對於產品產出物（Increment）的一種承諾，意即所有發布的變動，皆有符合 DoD 的標準，保障其品質。

這也就揭示了 DoD 與 AC 的不同，DoD 是對於品質的定義，適用於每一張待辦事項；而 AC 則是針對某張待辦事項，對於邊界的描述，也就是範疇。兩者是不同的概念。

而會有 DoD 的由來，其實也挺有趣的。軟體開發由於過去的分工明確，在不同的角色間對於「完成」這詞的定義可能僅限於與職責自己有關的事情。

比如說開發工程師認為自己只要把程式碼寫出來就好，頂多自己手動跑一下正常路徑是不是有過就都算有責任的了，其他的事情都是其他角色的事，比如說測試工程師、比如說維運工程師。

那對於這件事容易火大的我想莫過於產品負責人或產品經理類的角色了，因為對他們來說完成就是能夠上線給使用者使用，且具有一定的品質。問了開發工程師說完成了，結果一直跳出錯誤，那豈不是火冒三丈。

但反過來說，對於專業的工程師是會有品質的堅持的，他們會認為一段邏輯程式碼若是沒有被測試程式給保護，那就算功能是可以運作的，但對於這次產品變動就不算完成。而如果產品使用者堅持要把這樣的產品變動上線，那想必也會惹怒這些人，畢竟上線若是出問題，還是這些大大要背鍋。

就像是汽車這樣的產品，總不能可以開上路了，就說完成了。那胎壓、引擎、冷氣等系統的控管與監測難道都不用管嗎？噢，我還沒提到煞車的測試呢！若讓車可以開更快的變動，讓煞車系統有點失靈，卻沒有測過，那得多可怕。

這些情境都反映了一個產品開發團隊，對於產品與其變動怎樣算完成，應該有一致的定義。而且一個產品應該也只會有一套定義，無論是幾個產品開發團隊都一樣。

在程式方面的 DoD 可能就是各類測試，比如說要寫單元測試、或是測試覆蓋率不得降低、或是有經過驗收測試、回歸測試等。在維運方面的 DoD 可能是有經過壓力測試。

但不只是技術方面，在設計與文案方面也是可以有 DoD 的，比如說是否有與行銷對過這樣的設計是否符合當地市場，或者是某些解釋術語的文案，是否有通過法務的檢核等。

這些 DoD 就是對產品的各種品質控管，但這些品質都經過把關了，我們才足以有信心將其釋出給使用者。

其實關於 DoD 還有滿多可以談的，但礙於時間限制，就只先講觀念，其他的先且按住不談。等其他元素都談得差不多後，或許會再寫個「續談完成的定義」，亦或是在整系列文章都完成後，在整合時補充進來。